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Background to the invention 

This invention relates to a method of processing a transaction, particularly a financial 
transaction by means of a personal communication device. 

The invention vynll be described mth reference to the use of a cellular telephone or mobile 
telephone as the personal communication device. In addition, the invention will be described 
with reference to a point of sale (POS) terminal or an automated teller machine (ATM) as a 
transaction temninal. This is done purely by way of example and It is not intended thereby to 
limit the invention. 
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Summary of the invention 

This invention provides a method of processing, by means of a personal communication 
device and a transaction terminal remote therefrom, a transaction involving a remote 
transaction processing authority, the method comprising the steps of: 

with the use of the personal communication device, formulating and encrypting, by 
means of a first encryption key and a code unique to the personal communication 
device, a transaction request to be transmitted to the transaction terminal and 
transmitting the transaction request to the transaction terrhinal; 

transmitting the transaction request from the transaction terminal to the transaction 
processing authority; 

at the transaction processing authority, receiving the transaction request and 
identifying the personal communication device using. the code unique to the personal . 

• communication device, retrieving the first encryption key, previously stored at the 
transaction processing authority in respect of the personal communication device, 
decrypting the encrypted transaction request using the first encryption key, processing 

. the transaction request and generating a process outcome message pertaining to the 
result of processing of the transaction request, generating a second encryption key, 
storing the second encryption key in the transaction processing authority, transmitting 
the second encryption key to the transaction terminal, encrypting the process outcome 
message using the second encryption key and transmitting the encrypted process 
outcome message to the personal communication device; 

within the personal communication device, extracting and storing the second 
encryption key and transmitting the encrypted process outcome message to the 
transaction terminal; and 

at the transaction terminal, decrypting the encrypted process outcome message and 
applying the decrypted process outcome message to actuate the transaction terminal. 

The second encryption key that is stored at the transaction processing authority and in the 
personal communication device may be used, in a following transaction processing cycle as 
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the first encryption key. 

The second encryption key is preferably generated, every time the transaction processing 
cycle is repeated, with the use of code hopping techniques. 

Code hopping is facilitated by the fact that the second encryption key is stored, both at the 
transaction processing authority and within the personal communication device, since this 
assists in synchronising the constantly changing keys. • 

In the process of encrypting the transaction request to be transmitted to the transaction 
processing authority the transaction request may conveniently be encrypted with the use, in 
addition to one or more of the first encryption key, a code unique to the personal: , 
communication device and transaction request data, of a code, such as a personal • 
identification number (PIN), unique to the person requesting the transaction. . 

To simplify and speed up processing, the identity, code of the personal communication device 
may conveniently be sent in clear text whenever it is sent. This will facilitate identification of 
the personal communication device and speed up decryption at the point of reception of the 
information concerned. 



The personal communication device may conveniently be constituted by a cellular telephone 
and the prefenred form of communication between the personal communication device and 
the transaction terminal is by way of a short range link, preferably an infrared link. This will 
add to the security of the system. 

The transaction terminal may be constituted by any piece of equipment capable of receiving 
communications from the personal communication device and performing a function in 
response to a request from the device. Examples of such transaction terminals are 
automated teller machines (ATMs), point of sale (POS) tenninals and the like. 

The transaction temiinal need not be limited to a financial transaction processing machine. 
For instance, the transaction tenninal could be a door or a gate that is opened in response to 
a signal from the personal communication device. 

The transaction processing authority will depend on the transaction termiSnal involved. If the 
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transaction terminal Is an ATM, then the transaction processing authority will be a bank or 
other financial institution. If the transaction terminal is a door or a gate, then the transaction 
processing authority might conveniently be constituted by the security system of the premises 
concerned. 

The invention Includes apparatus and equipment adapted for implementation of the method of 
the invention. 



Brief description of the drawings 

The invention will be further described with reference to the accompanying drawings in which: 

Figure 1 is a blocl< diagram illustrating apparatus for implementing the method of the, . 
invention; 

Figure 2 is a block diagram illustrating (partly in flow-chart form), one implementation ' 
of the method of the invention. 



Description of embodiments of the invention 

The system 1 0 illustrated in figure 1 is a transaction processing system that utilises a cellular 
telephone 12 to communicate with a POS terminal or ATM 14. Transactions requested within 
the transaction processing system 1 0 will require authorisation by a transaction processing 
authority constituted, in this case, by a financial services provider 1 6. For ease of reference, 
the transaction temiinal will be taken to be an ATM. 

Communications between the ATM 1 4 and the financial services provider 1 6 are by way of a 
GSM communicator 1 8. Altematively or in addition, communication between the ATM 14 and 
the financial services provider 16 may take place on conventional communication networks 
incorporating the ATM 14, such as a conventional telephone network. 

To enhance the security of the transaction processing system 10, communications between 
the cellular telephone12 and the ATM 14 are by way of very short range communications 
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links. Most cellular telephones are equipped with Infrared transceivers 20. Infrared is a 
relatively secure form of short range communication. The ATM 14 can be fitted with an 
infrared transceiver 22 relatively simply. 

A person wishing to initiate a transaction simply enters the transaction details on the cellular 
telephone 12 and, using the appropriate features on the telephone, transmits a first infrared 
signal 24 to the ATM 14. 

This process is best illustrated with reference to^ Figure 2. . . . 

As can be seen from Figure 2, a person wishing to initiate a transaction starts off by entering 
transaction data (Drrr) into the telephone 12; Upon registration within the transaction 
processing system 10, the person concerned will have been issued with a personal- 
identification number (PIN) and at this point the person will be prompted to enter the PIN as 
data (Dpin) into the cellular telephone 12. Within the cellular telephone 12; the data so 
entered (DTrr and Drin) will be encrypted using a first encryption key (K1) as well as the . 
identification number (ID) of the telephone 12 (which may be a manufacturer's serial number 
or some other telephone identification number allocated upon registration within the system 
10) and the data previously entered (Dp,N and Drrr ). Not all of this information needs to be 
used in preparing the encrypted transaction request - E(DTrr). 

The encrypted transaction request (ECDjrr)) is then transmitted to the ATM 14 by way of a first 
infrared transmission 24. The telephone ID can be sent as clear text. 

On receipt within the ATM 14, the encrypted transaction request (E(DTrr) ) together with the 
telephone ID is transmitted by way of a transmission 26 to the financial services provider 16. 

The message received at the financial services provider 16 (E(DTrr):ID) must now be 
decrypted. 

The financial services provider 1 6 has data pertaining to the user and the telephone 1 2 stored 
in its databases, which data is linked to the telephone 1 2 by way of the telephone ID, the most 
important being data pertaining to the user's PIN (Drin) and the first encryption key (K1). The 
manner in which encryption keys are generated and stored will be described in more detail 
below. 
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On receipt of the encrypted transaction request (E(DTa):ID), the financial services provider 16 
retrieves this stored data and. using this data (particularly K1:Dpin) It is able to decrypt the 
encrypted transaction request (E(DTa))and to process the transaction request. 

The outcome of this process will either be positive (for instance to dispense funds or to 
display account infomiation) or there will be some other outcome (for Instance, not to 
dispense funds or not to display account Information, transferfurftls otsome other message). 

The process outcome message must be communicated both to the person requesting the 
transaction and to the ATM 14, since the ATM- 14 In particular will be required to perform 
certain functions in response, thereto. In view of the potential sensitivity of this inforniation,. 
this information is encrypted. 

The process of encryption is undertaken by the financial services provider which generates a 
secotid encryption key (K2). The second encryption key (K2) is.stored in the databases of the 
financial services provider 16 and linked to the telephone ID to facilitate future retrieval of the 
key. The second encryption key (K2) or a derivative thereof will be used as the decryption key 
(K1) in the next transaction processing cycle. 

Assuming that the transaction is authorised, the financial services provider generates a 
transaction authorisation message (Dyra). The financial services provider 16 encrypts the 
transaction authorisation message (Dyra) using the second encryption key (K2) and other data 
typically the telephone ID, the PIN number (Dp,n) and the data pertaining to the transaction 
authorisation message (Chra). 

The encrypted transaction authorisation message (E(DTra)) is then transmrtted to the 
telephone 12 by way of the GSM networi<, the most convenient form of transmission being as 
a Short Message Sen^lce (SMS) message 28. At the same time, the financial services 
provider 16 transmits the second encryption key ((K2)) to the ATM 14, by way of a 
communication 30 between the financial services provider 16 and the ATM 14. 

On receipt within the telephone 1 2. the encrypted transaction authorisation message (E(DTra)) 
is transmitted to the ATM 1 4 by way of a second infrared message 32. 
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Within tfie ATM 14 the encrypted transaction authorisation message (E(DTra)) is decrypted 
using the second encryption key (K2) received from the financial services provider 1 8. The 
second encryption l<ey (K2) is transmitted to the telephone 12 as part of the infrared 
communication 32 and the decrypted transaction authorisation message (Drra) is used to 
direct the operation of the ATM 14. In this example, the ATM 14 is instructed to dispense 
funds to the person who originally requested the transaction. 

Within, the telephone 12, the second encryption key (K2) Is novy stored in a database. When 
next the person wishes to commence a transaction processing cycle,lthe second encryption 
key (K2) stored in the telephone database is used as the initial encryption key (K1) in that next 
transaction. The second encryption key (K2) stored at the financial sen/Ices provider 16 will 
then be used as a decryption key and a new second encryption key (K2) will be generated In 
that next transaction. In this manner, the encryption keys are keptin synchronicity. A nuraber • 
of methods are known within code hopping techniques to ensure that security is maintained 
and replay attacks are avoided. In addition, techniques are known to ensure that key 
synchronisation remains possible in the event that an abortive process results in possible key : 
mismatch. 

The financial transaction process related above is but one example of the transaction 
processing capacity of the system. 
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